[% setvar title Standardize ALL Perl platforms on UNIX epoch %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='TITLE'></a><h1>TITLE</h1>
<p>Standardize ALL Perl platforms on UNIX epoch</p>
<a name='VERSION'></a><h1>VERSION</h1>
<pre>  Maintainer: Nathan Wiger &lt;<a href='mailto:nate@wiger.org'>nate@wiger.org</a>&gt;
  Date: 14 Aug 2000
  Last Modified: 28 Sep 2000
  Mailing List: <a href='mailto:perl6-language-datetime@perl.org'>perl6-language-datetime@perl.org</a>
  Number: 99
  Version: 4
  Status: Frozen</pre>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<p>Currently, internal time in Perl is maintained via <code>time</code>, which is
highly system-dependent. On some systems, this is relative to the UNIX
epoch, while others use their own epochs (MacPerl uses 1904, for
example).</p>
<p>All versions of Perl on all platforms should maintain time both
internally and externally as seconds since the UNIX epoch (00:00:00 01
Jan 1970 UTC).</p>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<a name='UNIX Epoch'></a><h2>UNIX Epoch</h2>
<p>Time is a dicey issue. While everyone disagrees on what the &quot;right&quot;
epoch is to use, everyone generally agrees that time synchronization
across different versions of Perl is a good thing.</p>
<p>The UNIX epoch is already a widely-established standard and seems as
good as any. This has the added benefit that most users will see no
change, since most users use a version of Perl which is already based on
the UNIX epoch.</p>
<a name='Other Time Properties'></a><h2>Other Time Properties</h2>
<p>Everyone seems pretty well agreed that while they want a standard epoch,
they also really want access to important alternative information, such
as ISO and native system time.</p>
<p>There are three alternatives:</p>
<pre>   1. Do not provide this information
   2. Add additional builtins to deal with this information
   3. Make time into a function that returns a polymorphic object</pre>
<p>Option 3 seems the most gracious, and nobody else was willing to even
entertain numbers 1 or 2. As such, we'll explore what could be returned
from said time object.</p>
<p>However, note this is only needed if we decide the other information is
important enough to be core-worthy. The opinion seems split on this one.</p>
<a name='Potential Time Object'></a><h2>Potential Time Object</h2>
<p>A time object could, conceivably, look like this:</p>
<pre>   $t = time;        # time object in scalar context

   $t++;             # -&gt;NUMBER, same as -&gt;unix
   print &quot;$t&quot;;       # -&gt;STRING, same as -&gt;unix

   $t-&gt;unix          # UNIX epoch seconds
   $t-&gt;iso           # ISO format
   $t-&gt;mjd           # modified julian date
   $t-&gt;native        # native time, whatever that may be</pre>
<p>For example. Despite offering it up as a possibility, however, this RFC
does not strictly require a time object be returned from <code>time</code>. Note
that by creating a polymorphic object <code>time</code> will look just like it
created a scalar to users, meaning they don't have to even know it's an
object if they don't want to.</p>
<a name='IMPLEMENTATION'></a><h1>IMPLEMENTATION</h1>
<p>The <code>time</code> core function must be changed to return the number of
seconds since the UNIX epoch on ALL platforms. Note this behavior is
inconsistent with previous versions of <code>time</code> and must be noted clearly
in the documentation.</p>
<p>The <code>time</code> value should be maintained as a 64-bit int (or float) with a
ridiculous amount of precision, per  RFC 7.</p>
<p>The issue is still open as to whether or not time should be maintained
internally via TAI or UTC. Both have their pros and cons. TAI is more
accurate, but does not have any close correlation to many platforms. UTC
has leap-second trickery, but has the distinct advantage that it would
remain consistent with UNIX platforms. This means <code>time</code> would appear
unchanged to all the Linux hackers, which is probably a good thing.</p>
<a name='REFERENCES'></a><h1>REFERENCES</h1>
<p>RFC 7:   Higher resolution time values</p>
<p>RFC 48:  Replace localtime() and gmtime() with date() and utcdate()</p>
<p>RFC 159: True Polymorphic Objects</p>
<p><a href='http://www.mail-archive.com/perl6-language-datetime@perl.org/msg00001.html' target='_blank'>www.mail-archive.com</a></p>
<p><a href='http://www.mail-archive.com/perl6-language-datetime@perl.org/msg00002.html' target='_blank'>www.mail-archive.com</a></p>
<p><a href='http://www.mail-archive.com/perl6-language-datetime@perl.org/msg00025.html' target='_blank'>www.mail-archive.com</a></p>
<p><a href='http://www.mail-archive.com/perl6-language-datetime@perl.org/msg00035.html' target='_blank'>www.mail-archive.com</a></p>
</div>
